1. Field of the Invention
This invention relates to computer systems, and more particularly to the enhancement of classes for data object persistence.
2. Description of the Related Art
Applications are often implemented as part of commercial and non-commercial business solutions for an enterprise. In some instances it is desirable that the data operated on and generated by an application be persisted to a persistent data store in order that subsequent invocations of the application may have access to the persistent data. One situation in which data persistence is beneficial is in the area of failure recovery. If an application server fails, information for the applications running in that server may be lost. Subsequent to the application server failure, the applications that it was running at the time of failure may be invoked on another server to take the place of those running on the failed server. If the application data were persisted to a persistent data store remote from the failed server and available to the newly invoked instances of the failed applications, processing could be resumed at the point of application server failure.
Typically, application state persistence is achieved through serialization. Serialization allows an object graph to be serialized into a stream, which can be associated with a file. The entire graph of objects reachable from the instance in then serialized into the stream. Serialization lacks features that may be desirable for distributed application systems. For example, there is no support for transactions. Without concurrency control, there is nothing to prevent multiple application component instances from serializing to the same file, thus corrupting state data. Serialization also lacks the ability to perform queries against the data. The granularity of access is an entire object graph, making it impossible to access a single instance or subset of the serialized data. Serialization includes no mechanism to determine when persistence updates should be performed. It therefore falls to the application developer to code the invocation points for serialization. Typically, this is done upon each request and results in large and for the most part unnecessary transfers of data among cluster members. Serialization can be a very time consuming operation.
An alternative to serialization is Java Data Object (JDO) persistence. In JDO persistence the classes of an application are enhanced such that each data field to be persisted is identified. Further, class enhancement provides calls to persistence mechanisms included in the JDO runtime environment when a data field to be persisted is accessed. This level of class enhancement allows for a granularity of persistence such that a single data field may be persisted. In addition, JDO persistence mechanisms can store persisted data objects to a persistent store such as a database according to an appropriate database schema. For example, with an application structure based schema, there may be a database table corresponding to each class of the application and the fields of a given class may be persisted to the table corresponding to that class. In another instance persisted fields of all application classes may be stored in a single table in the persistent store.
The basis for JDO enhancement of application classes is user-provided metadata input. Metadata is usually supplied by a user to the JDO enhancer in the form of a metadata file. The exact format of this file is specified by the provider of the JDO runtime environment, and in general it includes information on the names and types of variables included in classes, the names of classes and superclasses included in an application, and information on the data store to which the class data fields are to be persisted.
Typically, the application architect, coders, and one or more persons intimately familiar with the characteristics of the persistent data store are compelled to refer to the metadata file specification supplied by the JDO runtime environment vendor and laboriously input data indicating which data fields from each class need to be persisted, the structural relationship of these fields to their classes and to one another, and how the fields are to be stored in the persistent store.